Alex Crichton [Fri, 6 Apr 2018 19:35:37 +0000 (12:35 -0700)]
Fix another issue of poisoning too eagerly
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257
Alex Crichton [Tue, 3 Apr 2018 18:42:44 +0000 (11:42 -0700)]
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Alex Crichton [Mon, 2 Apr 2018 15:48:53 +0000 (08:48 -0700)]
Remove rustfmt from Travis
As discussed at the recent work week this is probably a bit too zealous at this
time, so let's hold off on it until it's either more stable or we figure out a
better way to deal with changes in rustfmt.
For now though it'll hopefully be easy to continue running rustfmt every so
often!
bors [Tue, 27 Mar 2018 18:14:32 +0000 (18:14 +0000)]
Auto merge of #5252 - matklad:new-context-new, r=alexcrichton
Supply units to the context at the point of creation
This slightly reshuffles `Context` creation. The main benefit is that we know the set of units when we do `Context::new`, so we could use it to precalculate more things.
bors [Tue, 27 Mar 2018 13:58:26 +0000 (13:58 +0000)]
Auto merge of #5249 - alexcrichton:run-rustc-less, r=matklad
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
Alex Crichton [Tue, 27 Mar 2018 11:55:23 +0000 (04:55 -0700)]
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
bors [Mon, 26 Mar 2018 13:00:26 +0000 (13:00 +0000)]
Auto merge of #5228 - phil-opp:target-spec, r=alexcrichton
Add support for absolute target.json paths
Builds upon https://github.com/rust-lang/rust/pull/49019 with the goal to provide a solution to https://github.com/rust-lang/cargo/issues/4905.
This PR does two things:
~~1. It appends a hash of the target path to the target folder name if a `*.json` path is passed as `--target`, like it's done in https://github.com/rust-lang/rust/pull/49019. This helps differentiating targets with the same JSON file name and avoids sysroot clashes in `xargo`.~~ See https://github.com/rust-lang/cargo/pull/5228#discussion_r176827531
2. It canonicalizes the passed target path (if it's a `*.json` path), so that the path stays valid when building dependencies and setting the `RUST_TARGET_PATH` environment variable is no longer necessary.
bors [Sat, 24 Mar 2018 16:59:59 +0000 (16:59 +0000)]
Auto merge of #5213 - Eh2406:faster_resolver, r=alexcrichton
Faster resolver: use a inverse-index to not activate the causes of conflict
This adds a test for https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 with two extensions that make it harder. It is the last reproducible and in the wild exponentially slow resolution (that I have found).
The problem in the test is `backtrack_trap0 = "*"` is a lot of ways of saying `constrained = ">=1.1.0, <=2.0.0"` but `constrained= "2.0.1"` is already picked. Only then to try and solve `constrained= "~1.0.0"` which is incompatible. Our parent knows that we have been poisoned, and wont try to activate us again. Because of the order we evaluate deps we end up backtracking to where `constrained: 1.1.0` is set instead of our parent. And so the poisoning does not help. This is harder then https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 because:
1. Having multiple semver compatible versions of constrained in play makes for a lot more bookkeeping. Specifically bookkeeping I forgot when I first submitted this PR.
2. The problematic dependencies are added deep in a combinatorial explosion of possibilities. So if we don't correctly handle caching that `backtrack_trap0 = "*"` is doomed then we will never finish looking thru the different possibilities for `level0 = "*"`
This PR also includes a proof of concept solution for the test, which proves that it does solve https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286. The added code is tricky to read. It also adds a `O(remaining_deps)` job to every activation on the happy path, slower if the `past_conflicting_activations` is not empty.
bors [Fri, 23 Mar 2018 15:28:44 +0000 (15:28 +0000)]
Auto merge of #5233 - lukaslueg:issue5229, r=matklad
Assert Dependency::name is never empty, prevent 'install ""' from crashing
An explicit `cargo install ""` would cause clap to pass an empty crate-name,
leading to a panic(). We now assert() that Dependency::name is never the
empty string and prevent the situation in the first place by not allowing
the crate-name to be empty for `install`.
Lukas Lueg [Fri, 23 Mar 2018 14:26:50 +0000 (15:26 +0100)]
Assert that Dependency::name is never empty, prevent 'install ""' from crashing
An explicit `cargo install ""` would cause clap to pass an empty crate-name,
leading to a panic(). We now assert() that Dependency::name is never the
empty string and prevent the situation in the first place by not allowing
the crate-name to be empty for `install`.
bors [Thu, 22 Mar 2018 14:07:49 +0000 (14:07 +0000)]
Auto merge of #5217 - matklad:known-crate-types, r=alexcrichton
Preprobe info for known crate type
Previously, we've calculated the set of crate types to learn about by
recursively walking the graph of units. However, to actually know
dependencies of a unit exactly, we must know target specific info, and
we don't know it at this moment (in fact, we are trying calculating it).
Note that crate-type calculation is already lazy, we don't have to calc
all crate-types upfront. So, let's just scrape this info once for
well-known crate types, and fill whatever is left lazily.
@alexcrichton would this approach work at all? I think it would, if `KNOWN_CRATE_TYPES` are all available for all target-tripples we support. Is it a valid assumption?
The larger picture is that I am trying to make unit dependency resolution eager and move it into the separate file. I even got something working, but I have to run dependency resolution three times, because it is not exactly idempotent for various reasons, including this target-info stuff :)
```
cx.prepare()?;
cx.build_unit_map(units.clone())?; // resolve dependencies
cx.probe_target_info(&units)?;
cx.build_unit_map(units.clone())?; // resolve again
cx.build_used_in_plugin_map(&units)?;
custom_build::build_map(&mut cx, &units)?;
cx.build_unit_map(units.clone())?; // and resolve one final time :)
```
projects / cargo.git / log